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The information contained in this document represents the current view held 
by OMTP Limited on the issues discussed as of the date of publication. 


This document is provided “as is” with no warranties whatsoever including any 
warranty of merchantability, non-infringement, or fitness for any particular 
purpose. All liability (including liability for infringement of any property rights) 
relating to the use of information in this document is disclaimed. No license, 
express or implied, to any intellectual property rights are granted herein. 


This document is distributed for informational purposes only and is subject to 
change without notice. Readers should not design products based solely on 
this document. 


Each Open Mobile Terminal Platform member and participant has agreed to 
use reasonable endeavours to inform the Open Mobile Terminal Platform in a 
timely manner of Essential IPR as it becomes aware that the Essential IPR is 
related to the prepared or published specification. The declared Essential IPR 
is publicly available to members and participants of the Open Mobile Terminal 
Platform and may be found on the “OMTP IPR Declarations” list at the OMTP 
Members Access Area. 


The Open Mobile Terminal Platform has not conducted an independent IPR 
review of this document and the information contained herein, and makes no 
representations or warranties regarding third party IPR, including without 
limitation patents, copyrights or trade secret rights. This document may 
contain inventions for which you must obtain licenses from third parties before 
making, using or selling the inventions. 
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1 INTRODUCTION 


1.1 DOCUMENT PURPOSE 


The aim of this document is to provide a Technical Recommendation for an 
open and standardised Visual Voice Mail (VVM) interface protocol which VVM 
clients may use to interact with a voice mail server. The key functions of this 
interface will be support of: 


* Message Retrieval 

* Message Upload 

¢ VVM Management 

* Greeting Management 
* Provisioning 


The document will not define how a VVM client looks nor will it define the 
general behaviour of a client/user interface or the manner in which a user 
shall interact with the user interface. The definition of the protocol may 
however imply certain client and/or user behaviours. The intention of the 
document is to ensure that the standard functionality of voice mail servers 
may be accessed through a range of VVM clients via a defined interface. This 
approach leaves scope for operators and vendors to differentiate their 
products. 


1.2 BUSINESS RATIONALE 


The growth of VVM services and possible new business models is restrained 
by the lack of a standardised client side interface to the voice mail server. 


Native support on terminals for a voice mail interface will significantly improve 
the overall user experience, which in turn will encourage wider use of voice 
mail services. 


If vendors are able to support a single VVM interface their time to market and 
associated costs shall be reduced. 


A standardised interface definition shall allow client developers to focus on 
producing better clients rather than modifying clients to work with multiple 
interfaces. 


Having only one interface to support will improve the ability of an operator to 
provide the VVM service on a variety of terminals, roll out the service more 
quickly and contain operational expenditure. 


A number of VVM implementations currently exist in the market, however, 
service deployment is at a nascent stage and therefore market fragmentation 
can still be prevented. It is imperative that vendors and operators achieve 
quick agreement on the core VVM interface. 
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1.3. INTENDED AUDIENCE 
The audience for this document includes: 


e Network operators who define specific requirements for VVM 
clients to be delivered on mobile Terminals which are delivered 
in accordance with the operators mobile requirements 
documents. 


e OMITP Terminal vendors, i.e. equipment and technology vendors 
who will deliver VVM clients on their Terminals. 


e Third party providers of VVM clients and servers. 


e Other projects inside OMTP that will take these requirements as 
input. 


1.4 COMPLIANCE REQUIREMENTS 


Conformance to this document does not offer a partial compliance option at 
the individual requirements level as is the case with most OMTP requirements 
documents. Conformance may only be stated if the vendor is 100% compliant 
to all aspects of the recommendation. 


This document is a Technical Recommendation for an open and standardised 
VVM interface protocol. VVM clients may use the interface protocol to interact 
with a voice mail server. The compliance statement encompasses only the 
interface protocol and does not state compliance to VVM functionalities 
implemented. 
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2 VVM INTERFACES OVERVIEW 


The VVM service enables third parties to develop terminal client applications 
for subscribers to manage their mailbox messages. Subscribers can use the 
VVM client on their terminals to listen to messages, delete messages, and 
compose messages. 


The following actions can be performed from the VVM client: 


° Message Retrieval: As described in section 2.1. 

° Message Deposit: As described in section 2.2. 

e  TUI (Telephony User Interface) Password Changes: As 
described in section 2.3 

e | TUI Language Settings Changes: As described in section 
2.4. 

e NUT (New User Tutorial) Session Disabling: As 
described in section 2.5. 

° Greeting and VS (Voice Signature) Management: As 
described in section 2.6. 


Examples of VVM message commands and responses are provided in section 
2.10. 


SMS (Short Message Service) messages sent between the VVM service and 
client, used to notify the client about events in the subscriber mailbox, query 
the subscriber’s provisioning status and activate and deactivate the service 
are described in section 2.9. Subscriber provisioning statuses are described in 
section 2.8. 


The VVM service complies with Request for Change (RFC) standards 
referenced in section 2.11. 
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2.1 MESSAGE RETRIEVAL INTERFACE DESCRIPTION 


The VVM client communicates with the VVM server via a standard IMAP4 
protocol for message retrieval. In addition to the IMAP4 RFC, some 
extensions have been added to enable the client to perform certain mailbox 
configuration actions, such as changing the Telephony User Interface (TUI) 
password and language. 


The number of concurrent IMAP4 sessions for a single client has a 
configurable limit. The client must log out at the end of a session. 


Commands used during the IMAP4 message retrieval sessions are described 
in section 2.1.1. 


The headers included in the messages retrieved via the VVM service are 
described in section 2.1.5. 


Message types and attachment formats supported by the VVM message 
retrieval sessions are described in sections 2.1.2 and 2.1.3. 


Some TUI features are limited by the VVM service, as described in section 
2.1.4. 
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2.1.1 MESSAGE RETRIEVAL: IMAP4 COMMAND REFERENCE 


The VVM service supports the IMAP4 commands listed in Table 1, with some 
restrictions described in this chapter. Other IMAP4 extensions are not 
supported, unless specifically stated. 





Command Name _RFC Reference 





APPEND RFC3501 
AUTHENTICATE RFC3501 for the DIGEST- 
MD5 algorithm (RFC 2831) 
only 
CAPABILITY RFC3501 
CHECK RFC3501 
CLOSE RFC3501 
EXAMINE RFC3501 
EXPUNGE RFC3501 
FETCH RFC3501 
GETMETADATA RFC5464 
GETQUOTAROOT RFC2087 
GETQUOTA RFC2087 
LIST RFC3501 
LOGIN RFC3501 
LOGOUT RFC3501 
NOOP RFC3501 
SEARCH RFC3501 
SELECT RFC3501 
SETMETADATA RFC5464 
STARTTLS RFC3501 
STATUS RFC3501 
STORE RFC3501 
UID RFC3501 








Table 1 Supported IMAP4 Commands 


When a server receives a command that is not listed in Table 1 and which 
thee server does not support, it will respond with the following error message: 


NO command not allowed 
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2.1.1.1 APPEND 
The VVM service supports the APPEND command, as described in RFC3501. ES 


TERMINAL 
PLATFORM 


The APPEND command is not supported on the Inbox folder. The APPEND 
command can be used only to append a new greeting to the Greetings folder. 


If the APPEND command is performed on the Inbox folder, the system returns 
the following error message: 


NO command not allowed 


The APPENDUID response code described in RFC4315 is supported. 
However, commands described in RFC4315 are not supported. 
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2.1.1.2 AUTHENTICATE 


The VVM service supports the AUTHENTICATE command described in 
RFC3501 for the DIGEST-MD5 algorithm (RFC2831) only. 


The AUTHENTICATE command includes the following credentials: 


Username: Defines the subscriber's IMAP4 user name as received in the 
STATUS SMS 


Password: Defines the VVM service password, and is either the subscriber’s 
IMAP4 password or the TUI password, depending on the system setup. 


The IMAP4 password is sent in the STATUS SMS message. If a TUl 
password is used, it must be set by the user. 


The table below describes error messages that can be returned for the 
AUTHENTICATE command. 


Description 

NO unknown user | The subscriber can not be located in the system. 

NO unknown The Client Type or Protocol Version is unknown. 

client 

NO invalid The password received from the client does not match 

password the password defined in the subscriber's profile. 

NO mailbox not The subscriber's mailbox has not yet been initialised via 

initialized the TUI (the VVM server can, by configuration, reject 
login attempts if the subscriber has not changed the 
default password/greeting via the TUl). 

NO service is not | The subscriber has not been provisioned for the VVM 

provisioned service. 

NO service is not | The subscriber is provisioned for the VVM service but 

activated the VVM service is currently not active (the VVM server 
can, by configuration, reject login attempts in such cases 
also) 

NO user is The Voice Mail Blocked flag in the subscriber's profile is 

blocked set to YES. 

No application There is a system error preventing authentication 

error 























Table 2 AUTHENTICATE Command Error Messages 
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2.1.1.3 CAPABILITY 
The VVM service supports the CAPABILITY command, as described in 
RFC3501. 


Note: The untagged response returned by the server indicates which 
authentication mechanisms are supported. Currently AUTH=DIGEST-MD5 
and STARTTLS LOGINDISABLED are returned. 


The QUOTA IMAP4 extension (RFC2087) and the IMAP METADATA 
extension (RFC5464) are also supported, as indicated in the CAPABILITY 
response. 

2.1.1.4 FETCH 

The VVM service supports the FETCH command, as described in RFC3501. 


Note: The Fetch item RFC822.SIZE, in addition to ALL, FAST, and FULL 
Fetch macros, return an inaccurate size value. 


Upon receiving the Fetch Body content, the attachment is transcoded to the 
format supported by the client. The size returned with the Fetch item 
RFC822.SIZE command is the size of the original attachment format, as 
stored in the server and not necessarily the size of the content sent to the 
client after the server performed any transcoding. 


A Partial Body Fetch, such as BODY[<section>]<<partial>> is not currently 
supported. If a partial fetch command is performed, the system returns the 
following error message: 


NO command not allowed 


If the user has no credit, the system may return the following error message: 


NO reservation failed 


2.1.1.5 GETMETADATA 


The GETMETADATA command, as defined in RFC5464, is used for the client 
to query the VVM server about some information. The "depth" and "maxsize" 
command options are not supported. 


All parameter names are defined in a namespace, with the following prefix: 
“/private/VVM/" 
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Table 3 Parameters supported by GETMETADATA, lists the parameters to be 
managed by the GETMETADATA command. It is envisaged that any new 
parameters included in this protocol will be managed via the METADATA 
extension rather than via SMS. 





Variable 


Values 


Comment 








GreetingTypesAllowed | Comma Separated List of zero or 


more of: 
7 personal 








This parameter 
defines the list 
of the greeting 











7 voiceSignature Sc a 
7 busyGreeting ee UM y 
7 noAnswerGreeting = 
" extendedAbsenceGreeting Sees 
Table 3 Parameters supported by GETMETADATA 
Example of usage for the allowed greeting: 
C: a GETMETADATA "" /private/VVM/GreetingTypesAllowed 





S: * METADATA "" 


S: a OK GETMETADATA complete 


(/private/VVM/GreetingTypesAllowed 
personal, voiceSignature, busyGreeting) 








The possible error responses are: 





Ss 





Ss 


a 


a 


BAD GETMETADATA invalid parameter 


NO GETMETADATA application error 








If the GETMETADATA command is used with parameters not defined in 
RFC5464 or not supported by the server, the error response will be: 





St 


St 





a 


a 


BAD GETMETADATA invalid command 











BAD GETMETADATA command not allowed 
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2.1.1.6 GETQUOTAROOT and GETQUOTA Commands 


The VVM service supports the GETQUOTAROOT and GETQUOTA commands, 
as described in RFC2087. All other commands in the quota extension are not 
supported. 


Both the GETQUOTAROOT and GETQUOTA responses include the total 
quota and the quota per media types for all mailbox folders. The following is 
the GETQUOTA response syntax: 


QUOTA " (STORAGE [occupied] [total] MESSAGE [occupied] 
[total] MESSAGE-soft [occupied] [total] empty-call-capture 
[occupied] [total] empty-call-capture-soft [occupied] [total] number 
[occupied] [total] number-soft [occupied] [total] fax [occupied] [total] 
fax-soft [occupied] [total] voice [occupied] [total] voice-soft 
[occupied] [total] video [occupied] [total] video-soft [occupied] [total] 
x-voice-greeting [occupied] [total] x-voice-greeting-soft [occupied] 
[total]) 


Where: 
e The media type returned in the GETQUOTAROOT or 


GETQUOTA responses depends on the media types 
supported in the system, including the following: 


fo) Voice 
O Fax 
O Video 


o © Greeting 
o Empty Call Capture 
o NUMBER message 


Additional media types might be returned in the response. Such 
media types shall be ignored by the client. 


e The soft quota represents the quota on which the 
subscriber is being notified. 


e The returned units depend on system initial setup. The 
default setup is as follows: 


o Voice messages = Length in seconds 
o Video messages = Length in seconds 
o Fax messages = Number of pages 
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o Greetings messages = Length in seconds 
o STORAGE = Size in KB 


o Empty Call Capture and NUMBER messages = number of 
messages 


The VVM service can be configured to return total storage only or a specific 
media type, such as voice only, fax only, video only, or greeting only. In this 
case the response syntax is as follows: 


* QUOTA "" (STORAGE [occupied]|[total]) 


2.1.1.7 LOGIN 
The VVM service supports the LOGIN command, as described in RFC3501. 


For the error messages that can be returned for the LOGIN command, refer to 
Table 2 AUTHENTICATE Command Error Messages. 


2.1.1.8 SEARCH 
The VVM service supports the SEARCH command, as described in RFC3501. 


Note: The BODY, LARGER, SMALLER, and TEXT search criteria must not be 
used. SEARCH commands performed with one of these attributes can 
respond with incorrect results, due to the differences between the media 
format stored in the server and the format returned to the client upon the Body 
Fetch command. 


2.1.1.9 SETMETADATA 


The SETMETADATA command, as defined in the RFC5464, is used for the 
client to set annotations, and it is only available in authenticated or selected 
states. 


All parameter names for this command are defined in a namespace, with the 
following prefix: “/private/VVM/". It is envisaged that any new parameters 
included in the protocol will be managed via the METADATA extension rather 
than via SMS. 


Table 4 Parameters supported by SETMETADATA, lists the parameters 
which are supported for the VVM service: 
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Variable Values 


Comment 





A list of the media 
formats supported by 
the VVM client. 


Accept 


Legal values: 


List of one or more 
voice media types 
listed in Table 5 
separated by a 
comma (,). 











This parameter 
defines the media 
formats supported by 
the client. 


A SETMETADATA 
command shall be 
issued by the client at 
the beginning of an 
IMAP session, right 
after a successful 
authentication with the 
VVM server. 








Table 4 Parameters supported by SETMETADATA 


Example of usage for the allowed greeting: 





C: a SETMETADATA "" 
"audio/amr,audio/wav; codec=g71la") 
S: a OK SETMETADATA complete 





(/private/VVM/Accept 








Possible error responses are: 





S: a BAD invalid parameter 


S: a NO application error 


working against old server) 





(wrong parameters) 
(server error) 


S: a BAD SETMETADATA unrecognized IMAP4 command 
(for backward compatibility in case of new client 








2.1.1.10 STARTTLS 


The VVM service supports the STARTTLS command, as described in 


RFC3501. 
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2.1.1.11 STATUS 

The VVM service supports the STATUS command, as described in RFC3501. 
The client application must not perform the STATUS command on the 
Greetings folder. The VVM server synchronises the greetings in the Greetings 
folder with the greeting in the TUI storage upon a SELECT Greetings 


command. If the STATUS command is performed on the greeting folder, the 
system returns the following error message: 


NO command not allowed 


2.1.1.12 Supported IMAP4 Flags 
The following standard IMAP4 flags are supported by the VVM service: 


e  \Seen: Indicates that the message was played 
e \Deleted: Indicates that the message was deleted 


e \Recent: Indicates that the message is "recently" arrived in this 
mailbox 


Note: Other standard or non-standard IMAP4 flags, must not be set by the 
client, except for the $CNS-Greeting-On flag (see section 2.7). 


If non-supported flags are set by the client, the system returns the following 
error message: 


NO command not allowed 
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2.1.2 MESSAGE RETRIEVAL: SUPPORTED MESSAGE TYPES OPEN 
The following message types can be retrieved via the VVM service: TERMINAL 
e Voice 
e Video 
e Fax 


° ECC (Empty Call Capture): An empty voice message. 

e NM (Number Message): An empty voice message 
including the number to which the reply is sent. 

e MDN (Message Disposition Notification): A system 
message advising the subscriber whether the message has 
been displayed, deleted, dispatched, or denied 


e DSN (Delivery Status Notification): A system message 
notifying the subscriber of the message delivery status 
(Delivered, Failed, or Delayed). 


e Infotainment: A voice message deposited directly to the 
subscriber mailbox by an external application. 


2.1.3 MESSAGE RETRIEVAL: SUPPORTED ATTACHMENT FORMATS 


Upon a Fetch Body command, the VVM server transcodes the message 
attachment to a format supported by the client. A message may have multiple 
attachments or components. Depending on how the TUI formats forwarded 
messages, a component may also encapsulate multiple components. 


All attachments are encoded in base64. 


The table below lists the file formats supported by the protocol. 















































Voice and AMR 12200 audio/amr 
Greeting WAV g711a audio/wav; codec=“g71la” 
attachments WAV g711u audio/wav; codec=“g711lu” 
QCELP 13300 audio/qcelp 
EVRC, 13000 audio/evre 
Video 3gpp h263_amr video/3gpp; codec=“h263 amr” 
attachments 
Fax attachments | PDF application/pdf 
Scripted Text Text plain/text 





Table 5 Supported Attachment Formats 
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2.1.4 VVM TUI FEATURES LIMITATIONS 


The VVM service has the following limitations relating to specific TUI features: 


Note: When these TUI features are used, the UID of the message on which 


Re-save: When a message is re-saved via the TUI, the 
original message is deleted and the internal date of the 
new message reflects the last date in which the message 
was re-saved. The original message deposit date can be 
obtained from the message Date header. 


ECC from the same Calling Line Identification (CLI) 
Aggregation: When ECC messages from the same CLI 
are aggregated, the internal date of the resulted message 
reflects the last missed call date. The date in which the 
ECC was first issued can be obtained from message Date 
header. 


the action was executed changes. 


2.1.5 MESSAGE RETRIEVAL HEADER REFERENCE 


The following types of headers are returned to the VVM client during message 


retrieval sessions: 


For examples of MIME messages, see VVM Message Command Examples. 
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Standard Root Level Message Retrieval Header 
Reference: Describes the standard message headers 
returned in the root level of the message 


VVM Specific Root Level Message Retrieval Header 
Reference: Describes the VVM specific message headers 
returned in the root level of the message 

Attachment Message Retrieval Header Reference: 


Describes the message header returned at the attachment 
level of the message 
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2.1.5.1 Root Level Message Retrieval Header Reference 


The following headers are returned to the VVM client during message retrieval Te ai 
sessions at the root level: PLATFORM 


Description: Defines the message originator. 
This header is mandatory. 


Note: In case of a restricted CLI, the VVM client 
should not rely on the From field, because the default 
value can change depending on the voice mail 
deployment. 


Legal Values: The phone number of the message originator, 
including the domain, in the following format: 


<phone-number>@<domain name> 
Default Value:in case of a restricted CLI, 
Unknown@<domain name> 


The client recognizes that the CLI is restricted 
if the left side of the email address is not a 
numeric phone number. 


Description: Defines the phone line numbers associated 
with the message. Multiple addresses are 
separated by commas. This header is 
mandatory. 


Legal Values: <main-phone>@<domain name> 
Default Value: N/A 
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Description: Defines the date that the message was sent. 


This header is mandatory. 


Note: It is the responsibility of the client to 
display dates in the time-zone of the client. 
The message received date is accessed from 
the internal date message attribute. The 
Internal date may not reflect the actual 
received time of the message when the Re- 
save or ECC aggregation features are used 
via the TUI (see VVM TUI Features 
Limitations). 


Legal Values: As defined in RFC2822. 
Default Value: N/A 


Example: 
Sun, 2 Sep 2007 07:36:05 +0000 (UTC) 


Description: Determines the message subject. 


This header is optional. 


Note: The VVM client should not rely on the 
Subject header to detect the message type. 
The message type should be detected 
according to the Message-Context header. 


Legal Values: Alphanumeric string (maximum length 90 


characters). 


Default Value:N/A 


© 2010 OMITP Lid. All rights reserved. No part of this document may be reproduced or 
transmitted in any form or by any means without prior written permission from OMTP Ltd. 


Page 21 of 89 


OMTP PUBLISHED 


OM 
TP 


OPEN 
MOBILE 
TERMINAL 
PLATFORM 


OMTP VISUAL VOICEMAIL INTERFACE SPECIFICATION v1.3 


2 | 
gqge= 
‘ h 


Description: Determines the message context. 
This header is mandatory. 


For MDN and DSN message types, this header 


specifies the original message type. 


Legal Values: Voice-message 
Video-message 
Fax-message 
X-empty-call-capture-message 
X-number-message 
X-voice-infotainment-message 


Default Value: N/A 


Description: Defines the length of the message, and is 
returned only for voice and video messages. 


This header is mandatory for voice and video 


messages. 


Legal Values: Length of voice or video content, in seconds. 


Default Value: N/A 
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Description: 


Legal Values: 


Default Value: 


Description: 


Legal Values: 


Default Value: 


Description: 


Legal Values: 


Default Value: 
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The message content type. This header is 
used to recognize MDN and DSN messages. 
This header is mandatory. 


Note: The VVM client can use this header 
value to distinguish between MDN or DSN 
messages and other messages. 


For voice messages: Multipart/voice-message 
or Multipart/mixed 


For fax messages: Multipart/fax-message or 
Multipart/mixed 


For video messages: Multipart/video-message 
or Multipart/mixed 


For ECC and number messages: Text/Plain 


For DSN messages: Multipart/report: report- 
type=delivery-status 


For MDN messages: Multipart/report; report- 
type=receipt-disposition-notification (or report- 
type=disposition-notification) 

For Infotainment messages: multipart/mixed 


N/A 


Determines the MIME version. 
This header is mandatory. 


1.0 (Voice Version 2.0) 
1.0 (Voice Version 2.0) 


Determines the message priority. 
This header is optional. 

Normal 

High 

Normal 
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Description: Determines the message sensitivity. 
This header is optional. 


Legal Values: Private 
Confidential 
Personal 


Default Value:N/A 


Description: Defines the number of fax pages in a fax 
message, and is relevant only for fax 
messages. 


This header is mandatory for fax messages. 
Legal Values: Integer 
Default Value:N/A 


Description: Used in case the message is the result of on-demand 
(asynchronous) transcription that replaced an original 
voice message. It contains the UID of that original 
voice message which no longer exists in the voice mail 
system (and may exist in the client cache). 


This header is optional. 


Note: The current message contains both voice message and the text 
transcription. 


Legal Values: UID as defined in RFC 3501 
Default Value:N/A 


2.1.5.2 Attachment Message Retrieval Header Reference 


The following header is returned to the VVM client during message retrieval 
sessions per attachment: 


Description: Determines the attachment content type. 
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The name and application parameters can optionally 
be added to this header. 


This header is mandatory. 


Legal Values: For Voice Messages: 
audio/wav; codec=g/711a 
audio/wav; codec=g711u 
audio/amr 
audio/qcelp 
For Fax Messages: 
application/pdf 
For Video Messages: 
video/3gpp; codec="h263_ amr" 
For Scripted Voice Messages: 
text/plain 
For nested messages: 
Message/rfc822 


Default Value:N/A 


Description: This header is added to text attachments 
(transcription result). It contains the content ID 
of the transcripted attachment. 


This header is optional. 


Legal Values: Source-ID= <id>, id value MUST equal to the 
value of Content-ID header of the transcripted 
body part (Content-ID header legal value is 
according to RFC 2111) 


Default Value: N/A 
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2.2 MESSAGE DEPOSIT INTERFACE DESCRIPTION 


The VVM service supports voice message deposit via the Simple Mail Transfer 
Protocol (SMTP) protocol as described in RFC2821. SMTP authentication uses 
the AUTH mechanism command as described inRFC 2554. 


The client may optionally use STARTTLS from RFC2595, RFC3207, 
RFC4642 for session encryption. 


In the SMTP AUTH (Digest MD5) command, the client is authenticated with a 
predefined username and password, supplied as part of the STATUS SMS. 


For an example of an SMTP authentication command, see SMTP MD5 
Authentication Example. 


Note: Only voice messages can be deposited via the VVM service. 


Only the Digest-MD5 algorithm is supported in the AUTH mechanism 
command. 


Delivery Status Notification (DSN) messages are deposited in the sender’s 
mailbox if one of the message recipients was not located. See Voice DSN 
Message Example for an example of DSN. 


For details about the headers included in deposited messages, see: 


e Standard Message Deposit Header Reference (section 
2.2.1): Describes message deposit headers that require 
specific values 


e VVM_ Specific Message Deposit Header Reference 
(section 2.2.2): Describes additional headers that can be 
added to the deposited message 


e Message Deposit Attachment Header Reference (section 2.2.3): 
Describes attachment headers that require specific values 


When forwarding or replying, the original should be attached as a message 
[RFC822] mime component. Putting the original as a message [RFC822] 
component in the reply/forward preserves all the header information of the 
original message. The TUI might need this information. The VVM server 
might have to reformat the message to the format that the TUI expects. 


2.2.1 STANDARD MESSAGE DEPOSIT HEADER REFERENCE 
The following RFC2822 message deposit headers require specific values: 
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OPEN 


Description: The Phone number and domain of the SEINE 


message sender. PLATFORM 
This header is mandatory. 


Legal Values: <phone-number>@<domain name> 


Default Value:N/A 
Example: 1234@Example.com 


Description: Defines the message addressee. Multiple 
addresses are separated by commas. 
This header is mandatory. 


Note: RCPT TO envelope headers are used 
to resolve the destination. The VVM client 
must set the RCPT TO envelope header in 
addition to the message TO field. 


Legal Values: <main-phone>@<domain name> 
Default Value:N/A 


Description: Defines the date that the message was sent. 
This header is mandatory. 

Legal Values: Date and time as defined by RFC2822 

Default Value:N/A 


Example: 
Sun, 2 Sep 2007 07:36:05 +0000 (UTC) 


Description: Defines the message subject. 
This header is optional. 


Note: The subject header is not available via TUI 
sessions, and can be displayed through web UI 
access. 
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The subject set by the client may be 
overridden by the VVM system with default 
values. 


Legal Values: Alphanumeric string (maximum length 90 
characters) 


Default Value:N/A 


Description: Defines the standard header for message 
presentation, based on RFC 3458. 


This header is mandatory. 
Legal Values: Voice-message 
Default Value:N/A 


Description: Defines the length of the message in 
seconds. 


This header is mandatory. 
Legal Values: Integer 
Default Value:N/A 


Description: Determines the message content-type. 
This header is mandatory. 
Legal Values: Multipart/mixed; 


Default Value:N/A 


Description: Defines the MIME version. 
This header is mandatory. 


Legal Values: 1.0 
Default Value:N/A 
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Description: Defines the message importance. 


This header is optional. 


Legal Values: High 
Normal (including Low importance) 


Default Value:Normal 


Description: Determines the message sensitivity. 


This is an optional header. 


Legal Values: Private 


Confidential 
Personal 


Default Value:N/A 


Description: Determines the message expiration date, 


after which the message is a 
purged by the server periodic proc 


This is an optional header. 


Legal Values: Date in the following format: 
DAY, D MMM YYYY HH:MM:SS (4+-)TTTT 


Default Value:N/A 
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2.2.2. VVM SPECIFIC MESSAGE DEPOSIT HEADER REFERENCE 


The following additional header fields can be added to the deposited 
message: 


Description: Determines the messaging action of the 
message. 


This header is relevant only for messages 
created using a messaging service and is 
applicable only to some VVM systems. 


This header is optional. 


Legal Values: reply = Indicates that the message is a reply 
to a subscriber's message 


forward = Indicates that the message was 
forwarded to the subscriber by another 
subscriber 


Default Value:N/A 


2.2.3 MESSAGE DEPOSIT ATTACHMENT HEADER REFERENCE 
The following headers must be set by the VVM client in the attachment level: 


Description: Determines the attachment content-type. 
This header is mandatory. 

Legal Values: message/rfc822 
Multipart/mixed 


See Table 5 Supported Attachment Formats 
for list of content-types. 


Default Value: N/A 


Description: Determines the content transfer encoding. 
This header is mandatory. 
Legal Values: base64 
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Default Value: N/A 


Description: Determines the attachment, along with the 
filename. 


The voice mail system ignores the path for the 
file. 


This header is mandatory. 
Legal Values: attachment; filename="<file name>" 
Default Value: N/A 

Example: 

attachment; filename="test.wav" 


Description: Defines the length of the voice attachment in 
seconds. 


This header is mandatory. 
Legal Values: Integer 
Default Value: N/A 
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2.3 TUIPASSWORD CHANGES INTERFACE DESCRIPTION OPEN 
MOBILE 


The VVM service enables the client to change the subscriber's TUI password Ra ap tes ena 
via a custom IMAP4 command. The change password command can be 

invoked only in the authenticated state, meaning that the user must be in the 
authenticated IMAP4 session. 


The password must be made up of numeric digits only. 


The password minimum and maximum length will be sent to the client in the 
STATUS SMS message (see STATUS SMS _ Description (System 
Originated)). 


For details about the command syntax used to change TUI passwords, see: 


e Change Password Request Syntax (section 2.3.1) 
e Change Password Response Syntax (section 2.3.2) 





2.3.1 CHANGE PASSWORD REQUEST SYNTAX 
The change password request syntax is as follows: 


CNS1 XCHANGE_TUILPWD PWD=<Value> OLD_PWD=<Value> 


The change password request syntax uses the following parameters: 


Description: Defines the new TUI password. 
This parameter is mandatory. 

Legal Values: Integer 

Default Value:N/A 


Description: The current TUI password that is being 
replaced. 


This parameter is mandatory. 
Legal Values: Integer 


Default Value:N/A 


In case of invalid command syntax, the 
following error is returned: 
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No unknown command 
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2.3.2 CHANGE PASSWORD RESPONSE SYNTAX OPEN 
MOBILE 
Upon successfully changing the password, the following response is returned: Bolger 


CNS1 OK password changed successfully 
The following errors can also be returned in the change password response: 
CNS1 NO password too short 


CNS1 NO password too long 
CNS1 NO password too weak 


CNS1 NO old password mismatch 


CNS1 NO password contains invalid characters 


CNS1 NO system error 
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2.4 CHANGE TUI LANGUAGE INTERFACE DESCRIPTION 


The VVM service enables the client to change the subscriber’s voice mail 
language via a custom IMAP4 command. The change language command 
can be invoked only in the authenticated state, meaning that the user must be 
in the authenticated IMAP4 session. 


The system supported languages is sent to the client in the STATUS SMS 
message (see STATUS SMS Description (System Originated)) 


For details about the command syntax used to change TUI languages, see: 


e Change Language Request Syntax (section 2.4.1) 
e Change Language Response Syntax (section 2.4.2) 


2.4.1 CHANGE LANGUAGE REQUEST SYNTAX 
The change language request syntax is as follows: 


CNS2 XCHANGE_VM_LANG LANG=<Language number> 


The change language request syntax includes the following parameter: 


Description: Determines the new language, and is one of 
the system supported languages as returned 
in the STATUS SMS (see STATUS SMS 
Description (System Originated)). 


This parameter is mandatory. 


Legal Values: String maximum 5 digits in the following 
format: 
<lang code>.<variant> 


The "lang code" is an ISO 639-2 value, 3 
characters max 


The "variant" is optional and is one (values 0 
to 9) digit indicating a speech characteristic or 
accent extension (for example a male or 
female voice). The definition of the variant 
value will be configured in the VVM client and 
server sides according to the operator policies 
and requirements. 
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Examples of valid values: 
Lang=eng 
Lang=eng. 1 


Default Value:N/A 


In case of invalid command syntax, the 
following error message is returned: 


No unknown command 
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2.4.2 CHANGE LANGUAGE RESPONSE SYNTAX 
OPEN 


Upon a successful language change, the following response is returned: MOBILE 
TERMINAL 
PLATFORM 


CNS2 OK language changed successfully 


The following possible errors can also be returned in the change language 
response: 

CNS2 NO invalid language 

CNS2 NO system problem 
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2.5 CLOSE NUT INTERFACE DESCRIPTION 


If available, the New User Tutorial (NUT) is implemented in the client. It is 
usually played the first time the user uses the VVM application if the 
subscriber status is “new subscriber” (see STATUS SMS Description (System 
Originated)). The VVM service enables the client to disable the New User 
Tutorial (NUT) flag in the server via a custom IMAP4 command to change the 
provisioning status of the customer in order for the server to avoid re-playing 
the TUI NUT. The CLOSE NUT command can be invoked only in the 
authenticated state, meaning that the user must be in the authenticated 
IMAP4 session. 


For details about the command syntax used to change TUI languages, see: 





e CLOSE NUT Request Syntax (section 2.5.1) 
e CLOSE NUT Response Syntax (section 2.5.2) 





2.5.1 CLOSE NUT REQUEST SYNTAX 
The CLOSE NUT request syntax is as follows: 


CNS3 XCLOSE_NUT 


In case of invalid command syntax, the following error is returned: 


No unknown command 


2.5.2 CLOSE NUT RESPONSE SYNTAX 
Upon successful NUT CLOSE, the following response is returned: 


CNS3 OK NUT closed 


Note: A successful CLOSE NUT command changes the VVM subscriber 
provisioning status and triggers a STATUS SMS message (see STATUS SMS 
Description (System Originated)). 


The following error can also be returned as part of the CLOSE NUT response: 


CNS3 NO system error 
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2.6 ON DEMAND AUDIO MESSAGE TRANSCRIPTION COMMAND 
SERVICES FROM VISUAL VOICE MAIL CLIENT 


The VVM service enables the client to order an audio message transcription 
via a custom IMAP4 command. It allows also START/STOP the transcription 
service. 


For details about the command syntax used to trigger the transcription, see: 


e On-demand transcription Request Syntax (section 2.6.1) 
e On-demand transcription response Syntax (section 2.6.2) 





For details about the command syntax used to START/STOP the service, see: 


e START/STOP service request Syntax (section 2.6.3) 
e START/STOP service response Syntax (section 2.6.4) 








2.6.1 ON-DEMAND TRANSCRIPTION REQUEST SYNTAX 
The on-demand transcription request syntax is as follows: 


CNS4 XTRANSCRIBE_ UID=< UID> 


The on-demand transcription request syntax includes the following parameter: 


Description: Determines UID of the audio message to be 
transcribed on-demand 


This parameter is mandatory. 
Legal Values: UID as defined in RFC 3501 
Default Value:N/A 


In case of invalid command syntax, the following error 
message Is returned: 


No unknown command 


2.6.2 ON-DEMAND TRANSCRIPTION RESPONSE SYNTAX 


Upon a successful on-demand transcription request, the following response is 
returned: 
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CNS4 OK Transcription order sent successfully 


The following possible errors can also be returned in the on-demand 
transcription response: 

CNS4 NO invalid UID 

CNS4 NO transcription service not available 


CNS4 NO system error 


2.6.3 AUTOMATIC TRANSCRIPTION SERVICE START/STOP REQUEST SYNTAX 


The VVM service allows the VVM client to control the automatic transcription 
service status. While the automatic transcription service is enabled, every new 
voice message deposited to the mailbox will be transcribed. 


The automatic transcription START/STOP request syntax is as follows: 
CNS5 XTRANSCRIPTION_SERVICE_ STATE=<START|STOP> 


The command includes the following parameter: 


Description: Determines the requested state of the 
automatic transcription service. 


Legal Values: "START" or "STOP" strings 
Default Value:N/A 


In case of invalid command syntax, the 
following error message is returned: 


No unknown command 


2.6.4 AUTOMATIC TRANSCRIPTION SERVICE START/STOP RESPONSE SYNTAX 
Upon a successful automatic transcription state change request, the following 
response is returned: 


CNS5 OK Transcription service is now <state>. 
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Where <state> is either "stopped" or "started". 


The following possible errors can also be returned in the response: 


CNS5 NO Transcription service remains unchanged 
CNS5 NO Transcription service unreachable 


CNS5 NO system error 
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2.7 GUIDELINES FOR GREETINGS AND VOICE SIGNATURE 
MANAGEMENT 


The VVM service enables the client to manage personalised greetings and 
voice signatures. Not all voice mail users want to leave a fully personalised 
greeting. The Voice Signature (VS) option allows users to leave a very short 
recording typically a couple of seconds long. The Voice Mail System would 
use this message, the voice signature, to replace the phone number in the 
default system voice mail greeting that a user hears when the call is diverted 
to the voice mail system. Thus, for example, instead of hearing the response 
"You have reached the mailbox of 12345678910, please leave a message 
after the beep", one would hear "You have reached the mailbox of Michel 
Arnaud, please leave a message after the beep”. 


Greetings (personalised and VS) are stored in the server in the subscriber’s 
Greetings Folder, in the format of a multipart-mixed message with an audio 
attachment. Personalised greetings and VS are distinguished by a specific 
header, as described in section 2.7.3. 


Several personalised greetings or VS can be flagged as “ON”. This flag 
indicates to the server that these messages are to be used by the voice mail 
system in the TUI session, according to the voice mail logic. 


lf several greetings of the same type are simultaneously flagged as ($CNS- 
Greeting-On) the voice mail system will play the one with the smallest 
message-sequence. If no personalised greeting or VS are flagged as (6CNS- 
Greeting-On) then the default system voice mail greeting will be played by the 
voice mail system. 


Greeting headers that require specific values and are set by the VVM client 
are described in section 2.7.3. 





See the following for details about how to upload or delete greetings or VSs 
from the Greetings Folder on the VVM server: 


e Uploading a Greeting or VS section 2.7.1 
e Deleting a Greeting or VS section 2.7.2 


Note: 


Greeting management error responses are formatted according to the IMAP4 
standard. 


In order to perform actions on the Greetings folder, the client application must 
issue the SELECT GREETINGS command. 
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The client application must not perform STATUS command on the Greetings 
Folder. 


2.7.1 UPLOADING A GREETING OR VS 


This procedure describes how to upload a personalised greeting or VS to the 
Greetings Folder. 


How: 
1. Use the IMAP4 APPEND command to append the 
message to the Greetings Folder. 
2. In order to activate a greeting, set the $CNS-Greeting-On 
flag. 
Note: 


The VVM client can append several personalised greetings and several VS to 
the Greetings folder, up to the quota limit. 


The flag can be set as part of the APPEND command or with a dedicated 
store command. 


The client must limit the recorded greeting or VS length according to the 
maximum greeting or VS length received in the STATUS SMS message (see 
STATUS SMS Description (System Originated)). 
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2.7.2 DELETING A GREETING OR VS 

This procedure describes how to delete a greeting or VS from the Greetings 
Folder. 

How: 


1. Flag the greeting or VS as deleted. 
2. Send the Expunge command. 


Note: 


Deleted greetings or VS flagged as (SCNS-Greeting-On) are not played by 
the VVM system, and the default greeting is played instead. 


2.7.3 GREETING HEADER REFERENCE 


The following greeting and VS headers require specific values, and 
must be set by the client. 


Description: Determines the greeting type. 
This header is mandatory. 


Legal Values: normal-greeting For Personalised greeting 


voice-signature For VS (Name greeting) 


busy-greeting For a personalised greeting 
when busy. If not recorded, 
normal greeting is used. If 
recorded, the normal greeting is 
used for the “no-answer” case, 
and the busy-greeting used for the 
“busy” case. 


extended-absence-greeting If this greeting 
is flagged “on’, it takes 
precedence over “normal” and 
“no-answer’ greetings. 


Default Value:N/A 
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Description: The phone number@Domain of the message 
sender. 


This header value is ignored by the server. 
Legal Values: N/A 
Default Value:N/A 
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Description: 


Legal Values: 


Default Value: 


Description: 


Legal Values: 


Default Value 


Description: 


Legal Values: 


Default Value 


Description: 


Legal Values: 


Defines the message subject. 
This header value is ignored by the server. 


N/A 
N/A 


Determines the message content type. 


This header is mandatory and appears in the 
message header and in the MIME part 
header. 


The greeting must include a single voice 
attachment at the root level only. 

Message header content-type: multipart/mixed; 
[boundary=<boundary -string>] 


MIME part content-type (must be encoded in 
base64): 

The valid values are the audio MIME types in 
Table 5 Supported Attachment Formats 


:N/A 


Defines the message addressee. 
This header value is ignored by the server. 


N/A 


:N/A 


Defines the MIME version. 
This header is mandatory. 


1.0 


Default Value:N/A 


Description: 
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Legal Values: base64 
Default Value:N/A 
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2.8 PROVISIONING STATUS OPEN 

MOBILE 
The provisioning status of a subscriber determines their access level to VVM JERMINAL 
services. 








Subscriber 
Unknown 


VV¥M provisioned=no 
VVM activated=no 
Blocked=NA, 

























VVM provisioning de- pro “isioning 


or Mailbox deletion ~ 









Subscriber 
Provisioned 
VVM provisioned=yes 


VVM activated=no 
Blocked=no 


VVM activation VVM activation 





V¥M de-activation VVM de-activation 



















Subscriber Subscriber 
New Ready 
VM provisioned=yes 





de SMA licter a Mailbox blocking Mailbox un-blocking 





VVM activated=yes 
NUT=off 
Blocked=no 


VVM activated=yes 
NUT=on 
Blocked=no 















Subscriber 







Mailbox blocking Blocked Mailbox blocking 
VVM provisioned=yes 

Mailbox un-blocking VM activated=NA, Mailbox un-blocking 
NUT=NA, 






Blocked=yes 


| de-provisioning 
‘or Maio deletion 


Subscriber 


Unknown 








NUT modification to off 








Figure 1: VVM Provisioning Status Transitions 
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The table below describes the possible status of VVM provisioning. 


VVM 


Provisioning 
Status 





Description 


NAVAN IRSY=1aYdCor- Ma [nay ox- Cea 























Subscriber The subscriber is not VVM service is not active: 

Unknown provisioned to the VVM e SYNC SMS will not be sent from the server. 
service or does not have a |e The server may send legacy notifications for voice 
mailbox in the voice mail mail deposit. 
system e STATUS SMS may be sent from the server. 

e The client must not initiate IMAP4 sessions. 
e The server will block IMAP4 session initiation 
attempts. 

Subscriber The subscriber is VVM service is temporarily not active: 

Provisioned provisioned to the VVM e SYNC SMS will not be sent from the server. 
service, while the VVM e The server may send legacy notifications for voice 
service is not activated yet. | mail deposit. 

e STATUS SMS may be sent from the server. 

e The VVM server will block IMAP4 session 
initiation attempts. 

e The VVM client may send activate SMS to change 
provisioning status to New or Ready. 

Subscriber The subscriber is VVM service is active: 

New provisioned to the VVM e SYNC SMS may be sent from the server. 
service, and the VVM e The server may send legacy notifications for voice 
service is active, while the mail deposit. 
subscriber has notgone |* STATUS SMS may be sent from the server. 
through NUT (New User | The VVM server allows IMAP4 session initiation 
Tutorial) session. attempts. 

e The VVM client may issue CLOSE_NUT 
command (to change provisioning status to 
READY). 

e The VVM client may send de-activate SMS to 
change the provisioning status to Provisioned. 

Subscriber The subscriber is VVM service is active: 

Ready provisioned to the VVM e SYNC SMS may be sent from the server. 
service, and the VVM e The server may send legacy notifications for voice 
service is active, while the mail deposit. 
subscriber has already e STATUS SMS may be sent from the server. 
gone through NUT e The VVM server allows IMAP4 session initiation 
session. attempts. 

e The VVM client may send de-activate SMS to 
change the provisioning status to Provisioned 

Subscriber The subscriber mailbox is | VVM service is temporarily not active: 

Blocked Blocked e SYNC SMS may be sent from the server. 

e The server may send legacy notifications for voice 
mail deposit. 

e STATUS SMS may be sent from the server. 

e The VVM server will block IMAP4 session 
initiation attempts. 








Table 4: VVM Provisioning States 
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2.9 VVM SMS INTERFACE DESCRIPTION 
The VVM service includes the following types of SMS messages: 


° System Originated SMS Messages: SMS messages sent to 
the VVM client to notify the client about a specific event in 
the subscriber's mailbox or profile. 

° Mobile (Client) Originated SMS Messages: SMS messages 
that enable the client to query the system about the 
subscriber's status, as well as to turn the service 
notifications on or off. 


The SMS format is based on the Terminal type, which is stored in the 
subscriber’s profile either during the service activation process (see Activate 
SMS (Client Originated) ) or by the operator’s customer support. 


The VVM service sends the VVM notifications to the client's VVM application 
port. The notifications have specific characteristics, as described in System 
Originated SMS Message Characteristics. 


Note: Depending on the Terminal type, it is possible to configure the VVM 
service to send legacy notifications in addition to the VVM notifications, in 
order to support a scenario in which the VVM subscriber SIM is switched to a 
non-VVM enabled Terminal that cannot process VVM notifications. 


If regular notifications are sent in addition to VVM notifications, it is the 
responsibility of the client to filter out the regular notifications according to the 
SMS source address or SMS Protocol Identifier. 


2.9.1 SYSTEM ORIGINATED SMS MESSAGES 
The VVM service sends the following SMS messages to the client: 


° SYNC SMS: Notifies the client that the status of a message 
or greeting in the mailbox may have been changed. 


For details see SYNC SMS Description (System Originated). 
e STATUS SMS: Notifies the client that the VVM subscriber's 
provisioning status was changed. 


For details see STATUS SMS Description (System Originated). 
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The maximum length for system originated SMS messages is 160 characters 
for 7bit encoding and 140 characters for 8bit encoding. It is recommended not 
to exceed the maximum SMS message length. 


If the SMS message exceeds the maximum message length, the Short Message 
Service Centre (SMSC) for both the operator and the client must support SMS 
concatenation. 


For more details about system originated SMS messages, see System 
Originated SMS Message Characteristics. 


2.9.1.1 SYNC SMS Description (System Originated) 


SYNC SMS messages are sent from the system to the client in order to notify 
the client that the status of a message or greeting in the mailbox may have 
changed. ASYNC SMS message will be sent when: 


e A new message has been deposited in the subscriber's 
mailbox, 


Additionally a SYNC SMS may be sent when one or more of the following 
events occur: 


° Message purge due to retention time exceeded, 
e — TUI session logout, 


e Greeting changed via the TUI, including a personalised 
greeting or VS recorded or deleted. 


In the SYNC SMS message, both the Client prefix and Prefix fields are 
followed by a colon (:), and all other fields are followed by semicolons (;). 
Each field is represented by the field name, an equal sign (=), and a legal 
value. Spaces are not allowed between parameters, although parameter 
values may include spaces. 


For details about SYNC SMS notification messages see SYNC SMS Field 
Reference and SYNC SMS Notification Examples. 


2.9.1.2 SYNC SMS Field Reference 
The following fields are used in SYNC SMS text that is sent to the VVM client: 
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Description: The definition is dependant on the client. Also 
see Client prefix in Activate SMS section 
2.9.2.2. 


This field is mandatory. 


Legal Values: Configurable string, unlimited length, always 
followed by a colon (:) 


Default Value://VVM 


Description: Determines the SMS type. 
This field is always followed by a colon (:). 


This field is mandatory. 


Legal Values: String, maximum four characters 
SYNC 


Default Value:SYNC 


Description: Determines the event that triggered the SYNC 
SMS. 


This field is mandatory. 


Legal Values: String, maximum three characters; 
NM = New message deposit,or update of a 
message with a text transcription, 
MBU = Mailbox update, including TUI session 
end or message purge, 
GU = Greetings/VS update. 


Default Value:N/A 


Description: Defines the message UID. 
This field is returned for new message events only, 
and the value can be used by the client for the IMAP4 
FETCH command, used to retrieve the message. 
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This field is mandatory. 


Legal Values: New message UID, maximum 21 digits. 


Default Value:N/A 


Description: Defines the number of new messages in the 


inbox. 


The client may use this field to show the 


number of new messages. 
This field is mandatory. 


Legal Values: Integer, maximum five digits. 
Default Value:N/A 


Description: Determines the message type. This field is 
returned for new message events only. 


The client may use this field to show the type 


of message. 
This field is mandatory. 


Legal Values: Maximum length one character; 
v = Voice, 
o = Video, 
f = Fax, 
i = Infotainment, 
e=ECC. 


Default Value:N/A 


Description: Defines the message sender 
originator Mobile Subscriber 


(message 
Integrated 


Services Digital Network Number (MSISDN)). 
This field is returned for new message events only. 


This field is not returned if the CLI 
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The client may use this field to show the 
message sender before initiating IMAP 
communication. 


This field is mandatory. 
Legal Values: Numeric string (phone number in E164 


format), maximum length 29 digits (30 
including the null terminator). 


Default Value:N/A 


Description: Defines the deposit date and time, in the time 
zone of the VM server. This field is returned 
for new message events only. 


The client may use this field to show the 
deposit time before initiating IMAP 
communication. 


This field is mandatory. 

Legal Values: Date and time in DD/MM/YYYY HH:MM TZ 
format. 
Maximum length 22 characters. 


Default Value:N/A 


Example: 
02/08/2008 12:53 +0200 


Description: Determines the message length. 
This field is returned for new message events only. 


This field is dependent on system 
configuration, and is used in the default setup. 
The client may use this field to show the 
length of message before initiating IMAP 
communication. 


This field is mandatory. 
Legal Values: Numeric string, maximum five digits, as 
follows: 


Voice, Video, and Infotainment messages: 
Length in seconds, 


Fax messages: Number of pages, 
Number and ECC messages: 0. 
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Default Value:0 


2.9.1.3 SYNC SMS Notification Examples 
The following is an example of system originated SYNC SMS notifications: 


OM 
TP 


OPEN 
MOBILE 
TERMINAL 
PLATFORM 


//VVM:SYNC: ev=NM; id=3446456; c=1; t=v; s=01234567898; dt=02/08/2008 


12:53 +0200; 1=30 


Fields used in the SYNC SMS messages are described in SYNC SMS Field 
Reference. 


2.9.1.4 STATUS SMS Description (System Originated) 


STATUS SMS messages are sent from the system to the client to notify the 
client about provisioning status changes. The VVM client is also able to query 
the VVM service for the current status. 


For details about provisioning status, see section 2.8. 


In the STATUS SMS message, the mandatory Client prefix field is following by 
a colon (:), as well as the mandatory Prefix field. All other fields are followed 
by semicolons (;). Each field is represented by the field name, an equal sign 
(=), and a legal value. Spaces are not allowed. 


For details about STATUS SMS notification messages see STATUS SMS 
Field Reference and STATUS SMS Field Examples. 
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2.9.1.5 STATUS SMS Field Reference 


The following fields are used in the STATUS SMS text that is sent to the VVM 
client: 


Description: The definition is dependant on the client. Also 
see Client prefix in Activate SMS section 
2.9.2.2: 


This field is mandatory. 


Legal Values: Configurable string, unlimited length, always 
followed by a colon (:). 


Default Value://VVM 


Description: Determines the SMS type. 
This field is always followed by a colon (:) 
This field is mandatory. 


Legal Values: String, maximum six characters 
STATUS 


Default Value:STATUS 


Description: Determines the subscriber's provisioning 
status. 
For details about provisioning status transitions, see 
section 2.8. 


This field is mandatory. 


Note: Depending on system configuration, the st value 
may appear between quotation marks. 


For example: 


st="N" 
Legal Values: Maximum length one character 


N = Subscriber New 
R = Subscriber Ready 
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Default Value: 


Description: 


Legal Values: 


Default Value: 
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P = Subscriber Provisioned 
U = Subscriber Unknown 
B = Subscriber Blocked 


N/A 


Determines the return code. When the VVM 
provisioning status is unknown one of the 
following codes is returned: 


Mailbox unknown: The user is unknown by 
the voice mail system, he does not have any 
voice mail box provisioned, even with a non- 
VVM service. 


VVM not provisioned: The user has a voice 
mail box provisioned on the voice mail 
system, but he does not belong to a class of 
service allowing him to use the VVM service. 


VVM not activated: The user has been 
provisioned with a VVM service on the system 
but the VVM service activation has failed. 


VVM client unknown: The Client Type or 
Protocol Version is unknown. 


VVM mailbox not initialised: The subscriber's 
mailbox has not yet been initialized via the 
TUI, so the VVM service cannot be activated. 


This field is mandatory. 


Maximum length one character; 
0 = Success, 

1 = System error, 

2 = Subscriber error, 

3 = Mailbox unknown, 

4 = VVM not activated, 

5 = VVM not provisioned, 

6 = VVM client unknown, 

7 = VVM mailbox not initialised. 


N/A 
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Description: Provide a URL. 
This URL may be used by the client to reach a server, 
in order for the user to subscribe to the VVM service. 


This field may be returned when the return 
code (rc) is "VVM not provisioned". 

Legal Values: String, maximum 100 characters 

Default Value:N/A 


Description: Determines the IMAP4/SMTP_ server IP 
address or Fully Qualified Domain Name. 


This field is mandatory, but is not returned for 
U and B events (see st). 


Legal Values: Prefix followed by VVM server IP address or 
Fully Qualified Domain Name, maximum 
length 30 characters. 


1:<IP address> 
2:<FQDN> 
Default Value:N/A 


Description: Determines the TUI access number. 
This field is mandatory. 


The client may use this field to show the 
visual voicemail TUI number. 


Legal Values: A telephone number, up to 16 digits. 
Default Value:N/A 
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Description: Determines the destination number used for 
addressing the VVM service. The destination 
number is used for a client originating SMS. 
This number is also configured in the 
Terminal but may be different in value. The 
VVM client must always use the latest number 
received from the server. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 


This field is mandatory. 


Legal Values: destination number, maximum length 30 
characters. 


Default Value:N/A 


Description: Determines the IMAP4 listening port. 


This field is not returned for U and B events 
(see st). 


This field is mandatory. 
Legal Values: IMAP4 port, maximum length 10 digits. 
Default Value:N/A 


Description: Determines the SMTP listening port. 
The client may use this field for SMTP deposits. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 
This field is mandatory. 

Legal Values: SMTP port, maximum length 10 digits. 


0 in case the server does not support 
SMTP protocol 


Default Value:N/A 
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OPEN 
Description: Determines the IMAP4 user name that is used MOBILE 
upon LOGIN, including domain. PLATFORM 


This field is not returned for U and B events 
(see st). 


This field is mandatory. 


Legal Values: IMAP4 username, maximum length 50 
characters. 


Default Value:N/A 


Description: Determines the IMAP4 password that is used 
upon login. 
This field is mandatory, but is not returned for 
U and B events (see st). 


Legal Values: IMAP4 password, maximum length 30 
characters. 


Default Value:N/A 


Description: Determines the list of languages supported by 
the VVM system. 
This field is used together with the change language 
command (see section 2.4). 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 
This field is mandatory. 

Legal Values: String, maximum length 36 characters. 
Multiple values are separated by a pipe (|). 
A language value will be in the following 


format: 
<lang code>.<variant> 


The "lang code" is an ISO 639-2 value, 3 
characters max 
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The "variant" is one digit indicating a speech TP 
characteristic or accent extension (for OPEN 
example a male or female voice). The variant TERMINAL 


is optional. The definition of the variant value one 


will be configured in the VVM client and 
server sides according to the operator policies 
and requirements. 


Example of valid value: 
lang=eng.1|eng.2|frelita|ger.1|ger.2 


Default Value:N/A 


Description: Defines the maximum greeting length 
allowed, in seconds. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 

The client may use the field for the Record 
Greeting feature (see Guidelines for 
Greetings and VS Management). 


This field is mandatory. 
Legal Values: Integer, maximum three digits. 
Default Value:N/A 


Description: Defines the maximum VS length allowed, in 
seconds. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 

The client may use the field for the Record VS 
feature (see Guidelines for Greetings and VS 
Management). 


This field is mandatory. 
Legal Values: Integer, maximum three digits. 
Default Value:N/A 
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Description: Defines the minimum and maximum TUI 
password length allowed. 
This field is used together with the change Password 
command (see section 2.3.1). 





This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 


The client may use the field for the TUI 
Password feature (see TUI Password 
Changes Interface Description). 


This field is mandatory. 

Legal Values: String, maximum five characters, in the 
following format: 
<min length>-<max length> 

Default Value:N/A 


Description: Defines the username used upon SMTP 
authentication. 
The client may use it for SMTP deposits. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 
This field is mandatory. 

Legal Values: String, unlimited length. 


0 in case the server does not support 
SMTP protocol 


Default Value:N/A 


Description: Defines the SMTP password used upon 
SMTP authentication. 
The client may use it for SMTP deposits. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 
This field is mandatory. 


© 2010 OMITP Lid. All rights reserved. No part of this document may be reproduced or 
transmitted in any form or by any means without prior written permission from OMTP Ltd. 


Page 62 of 89 OMTP PUBLISHED 


OMTP VISUAL VOICEMAIL INTERFACE SPECIFICATION v1.3 


Legal Values: String, unlimited length. 


0 in case the server does not support 
SMTP protocol 


Default Value:N/A 


Description: Defines if the pin code must be reset by the 
user at the VVM service activation. 


This field is sent only for new provisioning status. 

This parameter, if set to Yes, does not prevent the 
client to activate the VVM service, but is an indication 
which may be used by the client as a condition to 
close the NUT. 


This field is mandatory. 


Legal Values: String, Maximum 1 character: 


Y 
N 


Default Value: N 


Description: Defines if a personal greeting or a voice 
signature must be reset by the user at the 
VVM service activation. 
This field is sent only for new provisioning status. 


If this parameter is set to Yes, it does not prevent the 
client activating the VVM service, but it is an indication 
which may be used by the client as a condition to 
close the NUT. 

This field is mandatory. 


Legal Values: String, Maximum 1 character; 


G = normal greeting, 
V = voice signature, 
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B = Both the normal greeting and the voice 
signature, 


N = Neither. 
Default Value: N 


Description: Defines the VVM server capabilities for a text 
transcription of a voice message. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 
This field is mandatory. 
Legal Values: String, Maximum 1 character; 
N = none (no voice to text capabilities), 
D = on user demand, 


A = automatic (for all messages), 
B = both automatic and on demand. 


Default Value: N 


Description: Defines the current state of the text 
transcription service for voice messages. 


This field is not returned for U and B 
provisioning status (i.e. st=U or st=B). 


This field is mandatory. 
Legal Values: String, Maximum 1 character; 


0 = OFF, 
1=ON. 


Default Value: 0 


2.9.1.6 STATUS SMS Field Examples 


The following are examples of STATUS SMS notifications: 
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TP 


OPEN 
OBILE 


//vvM: STATUS : St=N; re=0; srv=1:10.115.67.251; tui=123;dn=999; ipt=143 ; TERMINAL 
spt=25; u=78236487@wirelesscarrier.com; pw=32u4yguetrr34; 
lang=eng|fre;q len=25;vs len=15;pw len=4-6; 

smtp u=super user@wirelesscarrier.com; 

smtp_pw=48769463wer; pm=Y; gm=N; vtc=D; vt=1 











//VVWM: STATUS: St=B; rc=0 


The fields used in STATUS SMS notifications are described in STATUS SMS 
Field Reference. 
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2.9.1.7 System Originated SMS Message Characteristics 
The outgoing SMS can be configured on the server according to the client 
type. 


For example, the default SMS configuration of a binary message sent by the 
server is according to TS23.040. An example of such a message is: 


e ESM class = 64 (for using UDH), 
e Data coding = 4 (8-bit encoding), 


e Protocol ID = 64 (Type 0 message indicating the mobile to 
acknowledge the message silently), 


e Application Port Addressing scheme in UDH = 5 (16bit 
address, 


° Destination Application Port Address = client's listening 
port on the Terminal by client as defined in section 2.9.2.2, 


e Replace flag = 1 (replace) for the following service types: 
o ForSYNC SMS messages due to Inbox change, 
o For STATUS and deactivate response SMS messages, 
o ForSYNC SMS messages due to Greeting change. 


These SMS parameters can be customised on the server. 


2.9.2 MOBILE (CLIENT) ORIGINATED SMS MESSAGES 
The client can send SMS messages to the server to do the following: 


° Query the provisioning status of the subscriber, using a 
STATUS SMS message (see STATUS SMS (Client 
Originated)), 


e Activate the service (see Activate SMS (Client Originated), 
section 2.9.2.2. 


e Deactivate the service (see Deactivate SMS (Client 
Originated), section 2.9.2.3. 


The VVM client sends the SMS messages to a destination number that is 
configured into the VVM client (see also the field dn in section 2.9.1.5). Upon 
receiving the VVM client SMS message, the SMSC finds the relevant VVM 
system and transfers the received SMS as an AT message. The VVM service 
then sends a response to the VVM client that sent the original message. 
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Note: The client must not depend on reliable delivery, and may retry a 
command that has not returned a response. 


2.9.2.1 STATUS SMS (Client Originated) 


The VVM client can send a STATUS SMS message to query the system 
about the provisioning status of the subscriber and the VVM server service 
settings. 


The following is an example of a client originated STATUS SMS message: 


OM 
TP 


OPEN 
MOBILE 
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PLATFORM 


STATUS: pv=<value>; ct=<value>; pt=<value>;<Clientprefix> 


Description: Determines the client type. 

This field is mandatory. 
Legal Values: String, (up to 30 characters). 
Default Value: N/A 


Description: This field may be used by the VVM client to 
change the default client prefix value 
“IIVVM" which is included in the SYNC and 
STATUS SMS (see sections 2.9.1.2 and 
2.9.1.5).. If not used by the client in the 
Activate SMS, the client prefix value sent in 
SYNC and STATUS SMS will remain as 
default. As an example, some VVM clients 
may need the client prefix to include a specific 
keyword and port number for client wakeup 
(instead of UDH). 


Legal Values: Configurable string (up to 30 characters), 
always followed by a colon (:). 


Default Value: N/A 
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Description: Application port 16 bit address (as described 
in 3GPP TS 23.040). This is the destination 
Terminal port number which the client is 
listening. The server may use this value for 
the destination application port address in the 
system-originated SMS message _ (see 
example in Section 2.9.1.7). 


In case the value is set to 0, the server may 
not send a binary message but either a legacy 
message or a different network specific 
message. The value of which is dependent on 
the client 


This is a mandatory field. 


Legal Values: Configurable string, maximum length = 30 
characters. 


1 — 16999: Application port addressing for 
GSM-networks. 


0: Non-GSM _ networks’ and __ legacy 
notifications. 


Default Value:N/A 


Description: Determines the protocol version. For 
example, version 1.3 of the protocol takes the 
value 13. 


This field is mandatory. 
Legal Values: 10-99 
Default Value: 13 


Upon receiving a STATUS query from the client, a STATUS SMS response is 
returned, as described in STATUS SMS Description (System Originated). 


Note: The STATUS SMS message is case-sensitive. 


2.9.2.2 Activate SMS (Client Originated) 
The client can send an Activate SMS in the following situations: 
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e To activate the service (change the VVM provisioning 
status from Subscriber Provisioned to Subscriber New or 
Subscriber Ready). Once the service is activated, VVM 
notifications are sent to the client. 


e To inform the server about a new client type, that is 
specified in the SMS and is saved in the subscriber profile. 


e Every time the user puts a new SIMCARD in the mobile to 
inform the server about the client capabilities. 


The following is the Activate SMS message syntax: 


Activate: pv=<value>; ct=<value>;pt=<value>;<Clientprefix> 


An Activate SMS message updates the subscriber’s VVM provisioning status 
and some Client information and results in a STATUS SMS, as described in 
STATUS SMS Description (System Originated). 


If the Activate SMS message is not successful, the following failure response 
is sent: 


//VVM:STATUS: st=U; rc=<error code> 


Description: Determines the client type. 

This field is mandatory. 
Legal Values: String, (up to 30 characters). 
Default Value: N/A 


© 2010 OMITP Lid. All rights reserved. No part of this document may be reproduced or 
transmitted in any form or by any means without prior written permission from OMTP Ltd. 


Page 69 of 89 OMTP PUBLISHED 


OM 
TP 


OPEN 
MOBILE 
TERMINAL 
PLATFORM 


OMTP VISUAL VOICEMAIL INTERFACE SPECIFICATION v1.3 


Description: 


Legal Values: 


This field may be used by the VVM client to 
change the default client prefix value 
“IIVVM’ which is included in the SYNC and 
STATUS SMS (see sections 2.9.1.2 and 
2.9.1.5). If not used by the client in the 
Activate SMS, the client prefix value sent in 
SYNC and STATUS SMS will remain as 
default. As an example, some VVM clients 
may need the client prefix to include a specific 
keyword and port number for client wakeup 
(instead of UDH). 


Configurable string (up to 30 characters), 
always followed by a colon (:). 


Default Value: N/A 


Description: 


Legal Values: 


Default Value: 
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Application port 16 bit address (as described 
in 3GPP TS 23.040). This is the Terminal 
destination port number where the client is 
listening. The server may use this value for 
the destination application port address in the 
system-originated SMS message (see 
example in Section 2.9.1.7). 


In case the value is set to 0, the server may 
not send a binary message but either a legacy 
message or a different network specific 
message. The value is dependent on the 
client. 


This is a mandatory field. 


Configurable string, maximum length = 30 
characters: 


1 — 16999: Application port addressing for 
GSM-networks, 


0: Non-GSM networks and legacy 
notifications. 


N/A 
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Description: Determines the protocol version without a 
decimal point. For example version 1.3 of the 
protocol takes the value 13. 


This field is mandatory 
Legal Values: 10-99 
Default Value: 13 


2.9.2.3 Deactivate SMS (Client Originated) 
The client can send a Deactivate SMS message to deactivate the service. No 
VVM SYNC notifications are sent to the client after service deactivation. 


The following is the Deactivate SMS message syntax: 


Deactivate:pv=<value>;ct=<string> 


A Deactivate SMS message updates the subscriber VVM provisioning status 
and results in a STATUS SMS, as described in STATUS SMS Description 
(System Originated). 


If the Deactivate SMS message is not successful, the following failure 
response is sent: 


//VVM:STATUS:st=U;rc=<error code> 


Description: Determines the client type. 

This field is mandatory. 
Legal Values: String, up to 30 characters. 
Default Value:N/A 


Description: Determines the protocol version without the 
decimal point. For example version 1.3 takes 
the value 13. 


This field is mandatory. 
Legal Values: 10-99 
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Default Value: 13 
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2.10 VVM MESSAGE COMMAND EXAMPLES 
The following are VVM command and response examples: 
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IMAP4 MD5 Authentication Example, 
SMTP MD5 Authentication Example, 
Voice Message Example, 

Video Message Example, 

Fax Message Example, 

ECC Message Example, 

Number Message Example, 

Voice DSN Message Example, 
Voice Message Disposition Notification Message Example, 
Deposit Voice Message Example, 
Greeting Message Example, 

Deposit Voice Message Example. 
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2.10.1 IMAP4 MD5 AUTHENTICATION EXAMPLE 


The following example illustrates the use of the required IMAP4 authentication 
command: 


Client: a0001 authenticate digest-md5 
cmVhbGO09ImVzdTFiLm1zdW5nLnRic3QiLG5vbmNIPSlyNzizN 
TU4Q0YwQzVGO 

UISNjJRFRDJCMkUORDcwNzY 
MjExNOExlixhbGdvcml0aG09Im1kNS1ZZXNzlixxb3A9ImF1dG 
gi 

Client: 

dXNicm5hbWU9InZs YWRAdmxhZC5jb20iLHJIYWxtPSJic3Ux 
Yid5tc3VuZy50ZXN 

Olixub25jZTOIMjcyMzU10E 
1RjICNZYORUQyQjJFNEQ3MDc2MkVDMjIxMTdBMSIsY25vbm 
NIPSJNVGs1T1R 
Fek1UTTVMakV3TkRnMk1UTXdPVFk9IlixuYz 
wMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJpbWFwL2Vzd 
TFiLm1zdW5nLnR 
Ic3QiLHJIc3BvbnNIPWU0Y2NhZDJkYTZiINW 
10DZIZTEZOWYOOTY3ZmU0 

Server: + 

cnNwYXVOaD1kYjQO0Y2U0ZjdjYZVkZTNIYzkyZmViZW RJOGNIZD 
YyMQ== 

Client: 

Server: a0001 OK login successful 


For more information about IMAP4, see RFC 2195. 
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2.10.2 SMTP MD5 AUTHENTICATION EXAMPLE 


The following example illustrates the use of the required SMTP authentication 
command: 


Client: ehlo mta.example.com 

Server: 250-esuic.example.com 

250-DSN 

250-8BITMIME 

250-PIPELINING 

250-HELP 

250-AUTH DIGEST-MD5 

250-DELIVERBY 300 

250-MEDIASIZE text:0Kb voice:0sec fax:0pages number:Obytes 
empty-call-capture:Obytes voice-infotainment:0sec 

250-SIZE OK 

Client: auth digest-md5 

Server: 334 
cmVhbGO9ImVzdTFiLmljb212ZXJZZS5jb20iLG5vobmNIPSJBNz 
Q3NTJEOEIWNZE2MzIDNOQzQzBCNkNDMjE1Mz 
QzMzgwNjQzMTZGlixhbGdveml0aG09Im1kNS1ZZXNzlixxb3A9I 
mF 1dGgi 

Client: 
dXNicm5hbWU9InVzZZXIxQGguaClscmVhbGO9ImVzdTFjLmljb 
212ZXJzZS5 
jb20iLG5vbmNIPSJBNzQ3NTJEOEIWNZE2MzIDNOQz 
QZBCNKNDMjE1MzQzMzgwNjQzMTZGlixjom9uY2U91k1UazVP 
VEV6TVRNNU 
xqRXdORGcyTVRNdO9SUWTOILG5jPTAWMDAWMDAXxLHFv 
cD1hdXRoLGRpZ2VzdC11cmk9ImIitYXAVZXN1MWMuaWNvbX 
ZicnNILmNvbSlis 
cmVzcG9uc2U9MDQ5ZmRIODI4OTFjIMmJhZTE20Tg1 
Y2FIYjJRMOWRjNTY= 

Server: 334 ... 

Server: 235 digest-md5 authentication successful 
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2.10.3 VOICE MESSAGE EXAMPLE 


The following example illustrates the use of voice message commands: 


Return-Path: <> 


Received: 


from msuic1 (10.106.145.31) by MIPS.SITE1 (MIPS 


Email Server) 


id 45879D 


D300000196 for 11210@vi.com; Tue, 19 Dec 2006 


12:12:09 +0200 

subject: voice mail 

MIME-Version: 1.0 (Voice Version 2.0) 
Message-Id: <31.24.2326006@msu31_24> 


Content-Type: Multipart/ voice-message; boundary="------------ 


Boundary-00= 90NIQYRXFQQMYJOCCJDO" 


From: 771 


004@vi.com 


To: 771000@vi.com 

Content-Duration: 17 

Message-Context: voice-message 

Date: Tue, 19 Dec 2006 10:12:09 +0000 (UTC) 


Boundary-00=_90NIQYRXFQQMYJOCCJDO 


Content-Type: Text/Plain 
Content-Transfer-Encoding: 7bit 
click on attachment 


Boundary-00=_90NIQYRXFQQMYJOCCJDO 


Content-Type: audio/amr 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename="vm.amr" 
Content-Duration: 17 


[message 
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2.10.4 VIDEO MESSAGE EXAMPLE 


The following example illustrates the use of video message commands: 


Return-Path: <> 


Received: 


from msuic196 (10.119.37.197) by MIPS.SITE1 


(MIPS Email Server) 


id 4545A1 


DF00039933 for 151515@rlcom.com; Wed, 20 Dec 


2006 12:13:48 +0200 

Subject: video message 

MIME-Version: 1.0 (Voice Version 2.0) 
Message-Id: <197.195.3706011@msu197_195> 
Content-Type: Multipart/Mixed; boundary="------------ 
Boundary-00=_7XAKIOLYA1UMYJOCCJDO" 
From: 8390@rlcom.com 

To: 151515@rlcom.com 

Content-Duration: 11 

Message-Context: video-message 

Date: Wed, 20 Dec 2006 07:46:19 +0000 (UTC) 


Boundary-00=_7XAKIOLYA1UMYJOCCJDO 


Content-Type: Text/Plain 
Content-Transfer-Encoding: 7bit 
Double-click on the attached video file 


Boundary-00=_7XAKIOLYA1UMYJOCCJDO 


Content-Type: video/3gpp; codec="h263_ amr" 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename="fffff2df.3gp" 
Content-Duration: 11 


[message 
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2.10.5 FAX MESSAGE EXAMPLE 


The following example illustrates the use of fax message commands: 


Return-Path: <> 


Received: 


from msuic1 (10.106.145.31) by MIPS.SITE1 (MIPS 


Email Server) 

id 458E1FCB0000183B for 111222333@vi.com; Mon, 25 Dec 
2006 17:02:06 +0200 

subject: fax mail 

MIME-Version: 1.0 (Voice Version 2.0) 

Message-Id: <31.24.2326073@msu31_24> 

Content-Type: Multipart/fax-message; boundary="------------ 
Boundary-00=_IF€4U6KM710OVNTT4D7THO" 

From: 797979@vi.com 

To: 111222333@vi.com 

X-Content-Pages: 3 

Message-Context: fax-message 

Date: Mon, 25 Dec 2006 15:02:06 +0000 (UTC) 


Boundary-00=_IF4U6KM71OVNTT4D7THO 


Content-Type: Text/Plain 
Content-Transfer-Encoding: 7bit 
click on attachment 


Boundary-00=_IF4U6KM71OVNTT4D7THO 


Content-Type: Application/pdf 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename="fax123.pdf" 
X-Content-Pages: 3 

[message attachment] 
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2.10.6 ECC MESSAGE EXAMPLE T a 
The following example illustrates the use of ECC message commands: ean 


TERMINAL 
PLATFORM 


Return-Path: <> 

Received: from msuic196 (10.119.37.197) by MIPS.SITE1 
(MIPS Email Server) 

id 4545A1DF00039C1E for 151515@rlcom.com; Wed, 20 Dec 
2006 16:07:41 +0200 

subject: empty message 

MIME-Version: 1.0 (Voice Version 2.0) 

Message-Id: <197.195.3706023@msu197_195> 
Content-Type: Text/Plain; boundary="------------ Boundary- 
00= ZQLK6RBOOM3NTT4D7THO" 

From: 4504@rlcom.com 

To: 151515@rlcom.com 

Message-Context: x-empty-call-capture-message 

Date: Wed, 20 Dec 2006 11:40:11 +0000 (UTC) 

4504 
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2.10.7 NUMBER MESSAGE EXAMPLE 
The following example illustrates the use of Number message commands: 


Return-Path: <9699999@system.com> 

Received: from aplus2 (172.17.5.44) by mips.system.com 
(MIPS Email Server) 

id 43EB428D00001 AFD for 1111111@system.com; Fri, 10 Feb 
2006 13:57:21 +0200 

subject: number message 

MIME-Version: 1.0 (Voice Version 2.0) 

Message-Id: <9.6.4252201@msu9_6> 

Content-Type: Text/Plain; boundary="------------ Boundary- 
00=_ R5EK7W5NTEPOO49D7THO" 

From: message@system.com 

To: 1111111@system.com 

Message-Context: x-number-message 

Date: Fri, 10 Feb 2006 09:58:39 +0200 (IST) 

523 
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2.10.8 VOICE DSN MESSAGE EXAMPLE 


The following example illustrates the use of Delivery Status Notification 


(DSN): 


Return-Path: <> 


Received: from msuic1 (10.106.145.31) by MIPS.SITE1 (MIPS 


Email Server) 


id 458A530000000D39 for 11410@vi.com; Fri, 22 Dec 2006 


05:02:28 +0200 


Message-ID: <458A530000000D39@MIPS.SITE1> (added by 


postmaster@MIPS.SITE1) 
subject: voice mail 


Content-Type: Multipart/report; report-type=delivery-status; 


boundary="------------ Boundary- 

00= 44NNCQ75B3NNTT4D7THO" 
From: 11310@vi.com 

To: 11410@vi.com 

Date: Fri, 22 Dec 2006 01:02:28 -0200 


This multi-part MIME message contains a Delivery Status 
Notification. If you can see this text, your mail client may not 
be able to understand MIME formatted messages or DSNs 
(see RFC 2045 through 2049 for general MIME information 
and RFC 3461, RFC 3463 DSN specific information). 
menennenenenee Boundary-00= 44NNCQ75B3NNTT4D7THO 


Content-Type: Text/Plain 


conccenenenens Boundary-00=_44NNCQ75B3NNTT4D7THO 


Content-Type: Message/Delivery-Status 
Reporting-MTA: smtp; msung.example.com 
Final-Recipient: 11310@vi.com 

Action: Failed 

Status: 5.4.3 (routing server failure) 


sonccenenenens Boundary-00=_44NNCQ75B3NNTT4D7THO 


Content-Type: Message/rfc822 

subject: voice mail 

MIME-Version: 1.0 (Voice Version 2.0) 
Message-Id: <31.24.2326058@msu31_24> 


Content-Type: Multipart/voice-message; boundary="------------ 


Boundary-00= 44NNHG35B3NNTT4D7THO" 
From: 11410@vi.com 
To: 11310@vi.com 
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Content-Duration: 78 


Message-Context: voice-message Onis 
Date: Tue, 19 Dec 2006 15:02:26 +0000 (UTC) PLATFORM 


sonenenennnens Boundary-00= 44NNHG35B3NNTT4D7THO 
Content-Type: Text/Plain 

Content-Transfer-Encoding: 7bit 

scencenesesens Boundary-00= 44NNHG35B3NNTT4D7THO 
Content-Type: audio/vnd.cns.inf1 
Content-Transfer-Encoding: base64 

Content-Disposition: attachment; filename="3ec6c(null).sbc" 
Content-Duration: 78 

[message attachment] 

sonenenennnens Boundary-00= 44NNHG35B3NNTT4D7THO-- 
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2.10.9 VOICE MESSAGE DISPOSITION NOTIFICATION MESSAGE EXAMPLE 


The following example illustrates the use of Message Disposition Notification 
(MDN) messages: 


Return-Path: <> 

Received: from aplus2 (172.17.5.44) by mips.system.com 
(MIPS Email Server) 

id 43EF8A6E00000668 for 1111111@system.com; Mon, 13 
Feb 2006 14:54:28 +0200 

Message-ID: <43EF8A6E00000668@mips.system.com> 
(added by postmaster@mips.system.com) 

subject: voice mail 

Content-Type: Multipart/report; report-type=receipt- 
disposition-notification; boundary="------------ Boundary- 
00=_XGBMBU3XFQQMYJOCCJDO" 

From: 3333333@system.com 

To: 1111111@system.com 

Date: Wed, 8 Feb 2006 10:55:45 -2200 

This multi-part MIME message contains a Message 
Disposition Notification. If you can see this text, your mail 
client may not be able to understand MIME formatted 
messages or MDNs (see RFC 2045 through 2049 for general 
MIME information and RFC 3798 for MDN specific 
information). 

sonenenennnene Boundary-00= XGBMBU3XFQQMYJOCCJDO 
Content-Type: Text/Plain 

soreenenennene Boundary-00= XGBMBU3XFQQMYJOCCJDO 
Content-Type: Message/disposition-notification 
Final-Recipient: 3333333@system.com 

Disposition: manual-action/MDN-sent-automatically; 
displayed 

soreenenenenne Boundary-00= XGBMBU3XFQQMYJOCCJDO 
Content-Type: Message/rfc822 

subject: voice mail 

MIME-Version: 1.0 (Voice Version 2.0) 

Message-Id: <9.6.4278007@msu9_6> 

Content-Type: Multipart/voice-message; boundary="------------ 
Boundary-00= XGBMGJZXFQQMYJOCCJDO" 

From: 1111111@system.com 

To: 3333333@system.com 
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Content-Duration: 2 Onis 
Message-Context: voice-message PLATFORM 


Date: Mon, 13 Feb 2006 10:44:36 +0200 (IST) 

soneneenenenen Boundary-00= XGBMGJZXFQQMYJOCCJDO 
Content-Type: Text/Plain 

Content-Transfer-Encoding: 7bit 

sonensenenenen Boundary-00= XGBMGJZXFQQMYJOCCJDO 
Content-Type: audio/vnd.cns.inf1 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename="48f36.sbc" 
Content-Duration: 2 

[message attachment] 

sonenennnnenen Boundary-00= XGBMBU3XFQQMYJOCCUJDO-- 


© 2010 OMITP Lid. All rights reserved. No part of this document may be reproduced or 
transmitted in any form or by any means without prior written permission from OMTP Ltd. 


Page 84 of 89 OMTP PUBLISHED 


OMTP VISUAL VOICEMAIL INTERFACE SPECIFICATION v1.3 


2.10.10 DEPOSIT VOICE MESSAGE EXAMPLE 


The following example illustrates the use of a Deposit Voice Message 
command. In this example, the client deposits an 18-second message. 


Message-ID: 
<10545552.1131961091850.JavaMail.icassagn@I20050329> 
Date: Wed, 21 Dec 2005 16:34:50 +0100 (CET) 
From: 5000250@example.com 

MIME-Version: 1.0 

Content-Type: multipart/mixed; boundary="---- 
= _Part_6_ 16713087.1135179290661" 
Importance: Normal 

Message-Context: voice-message 
Content-Duration: 18 

Expires: Sat, 31 Dec 2005 00:00:00 +0100 (CET) 
a-=-== = Part_6_16713087.1135179290661 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 8bit 

Open the attached file 

a-==== = _Part_6_16713087.1135179290661 
Content-Type: Audio/wav; codec=g711a 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; 
filename="wav_00000002.wav" 
Content-Duration: 18 

[message attachment] 

a-=-=- = Part_6_16713087.1135179290661-- 
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2.10.11 GREETING MESSAGE EXAMPLE T a 
The following example illustrates the use of a greeting message: ean 
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X-CNS-Greeting-Type: normal-greeting 
Message-ID: <1232456789.example4u@MGU_5> 
Date: Thu, 27 Mar 2008 17:37:02 +0200 

From: 3333333@system.com 

To: 1111111@system.com 

Subject: append personalised greeting 
Mime-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="----=_Part_10_6838114.1062660453543" 
Content-Duration: 8 

a-==== = _Part_10 6838114.1062660453543 
Content-Type: Audio/AMR; 
name="greeting.amr" 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; size=3724; 
filename="greeting.amr" 

[message attachment] 

a-=-== = _Part_10_ 6838114.1062660453543-- 


2.10.12 VS MESSAGE EXAMPLE 
The following example illustrates the use of a VS message: 


X-CNS-Greeting-Type: voice-signature 
Message-ID: <1232456789.example4u@MGU_5> 
Date: Thu, 27 Mar 2008 17:37:02 +0200 

From: 3333333@system.com 

To: 1111111@system.com 

Subject: append VOICE SIGNATURE 
Mime-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="----=_Part_10_6838114.1062660453543" 
Content-Duration: 8 

a-=-=- = _Part_10_ 6838114.1062660453543 
Content-Type: audio/qcelp; name=vs.qcp 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename=vs.qcp 
[message attachment] 

a-==== = Part_10_6838114.1062660453543-- 
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2.11 REFERENCE 


The VVM service complies with the following RFC standards: 


Also refer to 3GPP TS23.040 Technical realization of Short Message Service 


(SMS). 


RFC Compliance Related to Internet Mail, 
RFC Compliance Related to IMAP4, 
RFC Compliance Related to SMTP. 


2.11.1 RFC COMPLIANCE RELATED TO INTERNET MAIL 


The VVM service complies with the following RFCs related to Internet Mail: 


RFC 2045: Multipurpose Internet Mail Extensions (MIME) 
Part One: Format of Internet Message Bodies (renders 
obsolete RFCs 1521, 1522, 1590), 

RFC 2046: Multipurpose Internet Mail Extensions (MIME) 
Part Two: Media Types, 

RFC 2195: IMAP/POP AUTHorize Extension for Simple 
Challenge/Response, 

RFC 2821: Simple Mail Transfer Protocol (renders obsolete 
RFCs 821, 974, 1869), 

RFC 2822: Internet Message Format, 

RFC 2831: Using Digest Authentication as a SASL 
Mechanism, 

RFC 3458: Message Context for Internet Mail, 

RFC 3461: Simple Mail Transfer Protocol (SMTP) Service 
Extension for Delivery Status Notifications (DSNs), 


RFC 3798: An Extensible Message Format of MIME 
content-type for Message Disposition Notifications. 


2.11.2 RFC COMPLIANCE RELATED TO IMAP4 
The VVM service complies with the following RFCs related to IMAP4: 
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RFC 2595: STARTTLS Plain text communication protocol 
to an encrypted TLS or SSL connection 


RFC 3501: Internet Message Access Protocol: Version 4, 
rev. 1, 
RFC 2087: IMAP4 QUOTA extension, 


RFC 4315: Internet Message Access Protocol (IMAP) - 
UIDPLUS extension, 
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e RFC 5464: The IMAP METADATA Extension. i a 
OPEN 

MOBILE 

TERMINAL 

2.11.3 RFC COMPLIANCE RELATED TO SMTP PLATFORM 


The VVM service complies with the following RFCs related to SMTP: 


e RFC 3207: STARTTLS Plain text communication protocol 
to an encrypted TLS or SSL connection 


e RFC 2554: SMTP Service Extension for Authentication, 


e RFC 3463: Enhanced Mail System Status Codes for 
Delivery Reports. 
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3 ABBREVIATIONS 










































































ABBREVIATION DESCRIPTION 

AT Application Terminated 

CLI Calling Line Identification 

DSN Delivery Status Notification 

ECC Empty Call Capture 

IMAP Internet Message Access Protocol 
MDN Message Disposition Notification 
MD5 Message-Digest algorithm 5 
MIME Multi-purpose Internet Mail Extension 
MSISDN oo Integrated Services Digital Network 
NUT New User Tutorial 

RFC Request For Change 

SMPP Short Message Peer to Peer 

SMS Short Message Service 

SMSC Short Message Service Centre 
SMTP Simple Mail Transfer Protocol 
SSL Secure Sockets Layer 

TLS Transport Layer Security 

TUI Telephony User Interface 

UDH User Data Header 

VS Voice Signature 

VVM Visual Voice Mail 
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